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(54) Method for achieving end-to-end quality of service negotiation for distributed multimedia 
applications 



(57) This invention presents a framework for achiev- 
ing dynamic End-to-End QoS-negotiation and control 
coordination, with distributed multimedia applications. 
The framework builds upon dynamic capability negotia- 
tion and specification of Adaptation Paths and (alterna- 
tive) QoS Contracts, based on user preferences. In par- 
ticular we present a protocol providing End-to-End ne- 
gotiation of alternative QoS, capabilities, and preferenc- 
es/configurations, based on extensions of IP-based pro- 
tocols like SIP/RTSP/SDP, in coordination with mecha- 
nisms for network resource reservation (e.g. RSVP), lo- 
cal terminal resource (e.g. CPU, memory, power, auxil- 
iary devices) reservation, and adaptation mechanisms. 
To this extent, and with respect to two or more peers 
(101, 103) this invention identifies six phases, through 
which said peers can establish multiparty, multi-stream, 
multimedia communications. In detail, the phases are: 
Protocol Discovery (104), Pre-Negotiation (106), Multi- 
Stream QoS Synchronization and QoS Correlation 
(107), Fast-Negotiation (obeying the Economy Princi- 
ple) (108), Re-Negotiation (obeying the Economy Prin- 
ciple) (109), Resource Reservation Release (110). All 
the six phases can be concatenated, or be executed at 
different times. 

This invention also presents the concept of the 
E2ENP Broker (105), an optional third-party entity, 
which can be used for relieving peers (101, 103) from 
performing the time- and resource-consuming Pre-Ne- 
gotiation phase (106) (and eventually also the Multi- 
Stream QoS Synchronization and QoS Correlation 



(107)). This entity may coincide with e.g. audio-Zvideo- 
conference bridges. 




Figure 2 
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Description 

[0001] The invention hereby presented generally relates to the field of distributed multimedia applications and tech- 
nologies. It includes research and development issues related especially to multimedia middleware, Quality of Service 
(QoS) Management, Resource Reservation mechanisms, mobile terminals, and wireless communication. 
[0002] At first the terminology used in the present description and the claims will be shortly explained: 



Term 


Definition 


Adaptation Path 


An ordered set of QoS contracts that indicate the users preferences and wishes. Typicalfy, the 
most important QoS contract is the first one in the path. 


Component 


A particular type of interaction (e.g. audio conversation) that can be realized using different 
applications 


Configuration 


A set of parameters required for implementing a variation of a certain component. Potential 
configuration indicates the system's functional capabilities, whereas actual configurations reflect 
the mode of operation of a particular instantiation. 



20 


Content negotiation 


Exchange of information leading to select proper representation when transferring data 


25 


Economy Principle 


The economy principle suggests to reserve the more expensive resources as the last 
ones. As network resources are shared among several clients and typically one has to 
pay for them, it is better to first reserve resources on all end systems and then resource 
network resources as the last step. 


Feature set 


Some sets of media features described by a media feature assertion 




Quality of Service, QoS 


The collective effect of service performance which determines the degree of satisfaction 
of a user of the service 1 


30 


QoS Change 


The change of the QoS contract initiated by the service user 




QoS Contract 


Agreement between a service user and a given service provider, specifying QoS 
requirements and constraints, as well as the policies required to keep track about QoS 
during all phases of said service. 


35 


QoS Contract Type 


Captures the structure of a class of QoS Contracts, by identifying how individual QoS 
Contracts specify the QoS properties over a given set of QoS parameter types (also 
known as dimensions in [Frolu98]). Each parameter type consists of a name and a 
domain of values. QoS specifications can be simply intended as a set of constraints over 
said domains, one per parameter type. 


40 


QoS Specification 


General term for identifying set of QoS parameters and constraints specified by a user. 



Definition from the ITU-T (former CCITT) Recommendation E.800 



QoS Violation 


The violation of a QoS Contract caused by the Service Provider 


Third party call control 


In third party call control, an external controller is creating, modifying and terminating 
sessions between other participants. 



[0003] Now the abbreviations used in the description will be explained: 

50 



ATM 


Asynchronous Transfer Mode 


CC/PP 


Composite Capabilities/Preference Profiles 


CSCW 


Computer-Supported Cooperative Work 


E2ENP 


End-to-End Negotiation Protocol 


HDTV 


High Definition Television 
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(continued) 



HTTP 


Hyper Text Transport Protocol 


IETF 


Internet Fnninperinn Task Fnrre 

N llul 1 IDl Ul lull ICUI M IU IClOfX 1 Ul uCr 


IP 


Internet Protocol 


IRT 


Initiator-Role-Token 


MSC 


Messaae Seauence Charts 


OS 


Operating System 


RDF 


Resource Description Framework 


RTP 


Real Time Protocol 


RTSP 


Real Time Streaming Protocol 


RSVP 


Resource Reservation Protocol 


SAP 


Session Announcement Protocol 


SDP 


Session Description Protocol 


SIP 


Session Initiation Protocol 


VoD 


Video on Demand 


UML 


Unified Modeling Language 


XML 


Extended Markup Language 



[0004] The following prior art documents are known to the inventors: 

[BeserOO] B. Beser, Codec Capabilities Attribute for SDP, IETF Internet-Draft, Work-in-progress, <dratt-beser- 
mmusic-capabilities-OO.txt>. 

[Bhatt99] S. Bhatti, G. Knight, Enabling QoS adaptation decisions for Internet applications, London, UK, 1 999. 

[Blake98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Serv- 
ices, IETF Request for Comments: 2475, December 1998. 

[Booch99] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison Wesley 
Longman, 1999. 

[BorOO] C. Bormann et. al., Simple Conference Control Protocol, IETF Internet Draft, Work-in-progress, <draft- 

ietf-mmusic-sccp-01 .txt>. 

[BumOO] L. Burness et al., The BRAIN Quality of Service Architecture for Adaptable Services with Mobility 

Support, in Proceedings of the PIMRC 2000, London, 2000. 
[CamaOO] G. Camarillo, Confirmation of SDP preconditions, IETF Internet Draft, Work-in-progress, <draft-ca- 

marillo-manyfolks-confiim-02.txt>. 
[CamaOOa] G. Camarillo, Third party call control with SDP preconditions, IETF Internet Draft, Work-in-progress, 

<draft-camarillo-3pcc-qos-00.txt>. 
[ConnegOO] G. Klyne (ed.), A revided media feature set matching algorithm, IETF media feature registration WG, 

Work-in-progress, < draft-klyne-conneg-feature-match-02. txt>. 
[ConnegOOa] G. Klyne (ed.), Identifying composite media features, IETF conneg working group, Work- in -progress, 

< draft-ietf-conneg-feature-hash-05.txt>. 
[Frolu98] S. Frolund, J. Koistinien, QML: A Language for Quality of Service Specification, HP-Lab Technical 

Reports, HPL-98-10, 980210. 
[Handl98] M. Handley, V. Jacobson, SDP: Session Description Protocol, IETF Request for Comments: 2327, 

April 1998. 

[Handl99] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, SIP: Session Initiation Protocol, IETF Request 

for Comments: 2543, March 1999. 
[Hand100] M. Handley, C. Perkins, E. Whelan, Session Announcement Protocol, IETF Request for Comments: 

2974, October 2000. 

[ISOX641] ITU-T Recommendation X.641 (12/97) I ISO/IEC 13236:1998, Information technology - Quality of 
Service: Framework. 

[Kassl99a] A. Kassler, P. Schulthess, An End-to-End Quality of Service Management Architecture for Wireless 
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[Kassl99b] 
[KasslOO] 

[KasslOOa] 

[LevinOI] 

[MandaOOa] 

[MandaOOb] 

15 [MarshOO] 

[Nahr95] 
[Ott99] 

20 [Pan99] 

[Pasqu92] 

25 [Pasqu93] 

[RFC2533] 
30 [RFC2703] 
[SIPRES01] 
[SDPCNOO] 

35 

[SDPCN01] 
[SDPNGOO] 
40 [Shulz98] 
[SIPRES01] 
[SMIL98] 



45 



[Yeado93] 



ATM networks, in: Proceedings of the HICSS 32, Mauii, Hawaii, USA, January 1999. 
A. Kassler, P. Schulthess, Extending the QoS Paradigm of Wireiess ATM to Mobile Broadband Appli- 
cations and to the User, in: Proceedings of the WCNC '99, September 1 999, New Orleans, USA. 
A. Kassler et al., BRENTA - Supporting Mobility and Quality of Service for Adaptable Multimedia Com- 
munication, in Proceedings of the 1ST Mobile Communications Summit 2000, Galway, Ireland, October 
2000, pp. 403-408. 

A. Kassler et al., An Open Endsystem Architecture for Adaptable Multimedia Services with QoS Sup- 
port, in Proceedings of the BRAIN workshop, London, 2000. 

O. Levin, SIP Requirements for support of Multimedia and Video, IETF Internet- Draft, Work-in- 
progress, < draft-levin-sip-for-video-OO.txt> 

D. Mandato, A universal QoS adaptation framework for mobile multimedia applications, European 
Patent Application 00 111 191.3, May 24, 2000. 

D. Mandato et al., High-level interface for QoS-based mobile multimedia applications, European Pat- 
ent Application 00 126 975.2, December 8, 2000. 

W. Marshall et al., SIP Extensions for Resource Management, IETF draft < draft-ietf-sip-manyfolks- 
resource-00>, November 2000. 

K. Nahrstedt and J. M . Smith, The QoS Broker, IEEE Multimedia Magazine, Spring 1 995 (2)1 , pp. 53-67 
J. Ott et. al., Capability description for group cooperation, IETF Internet-Draft, Work-in-progress, 
<draft-ott-mmusic-cap-00. txt>. 

P. Pan, H. Schulzrinne, YESSIR: A Simple Reservation Mechanism for the Internet, Computer Com- 
munications Review (CCR), Vol. 29, No. 2, pp. 89-101 , April 1999. 

J. Pasquale, G. Polyzos, E. Anderson, V. Kompella, The Multimedia Multicast Channel, Proc. of 3rd 
I ntemational Workshop on Network and Operating System Support for Digital Audio and Video (NOSS- 
DAV 92), San Diego, California, November 1992, pp. 185-192. 

J. Pasquale et al., Filter Propagation in Dissemination Trees: Trading Off Bandwidth and Processing 
in Continuous Media Networks, Proc. of NOSSDAV 93, Lancaster University, Lancaster, UK, 1993, 
pp. 269-278. 

RFC 2533, A Syntax for Describing Media Feature Sets, Graham Klyne, 5GM/Content Technologies, 
March 1999. 

RFC 2703, Protocol-independent Content Negotiation Framework, Graham Klyne, 5GM/Content Tech- 
nologies, September 1999. 

W. Marshall et. al., Integration of Resource Management and SIP -SIP Extensions for Resource Man- 
agement, IETF SIP working group, Work-in-progress, <draft-ietf-sip-manyfolks-resource-01 .txt>. 
F. Andreasen, SDP Simple Capability Negotiation, IETF MMUSIC working group, Work-in-progress, 
< draft-andreasen-mmusic-sdp-simcap-00.txt>. 

F. Andreasen, SDP Simple Capability Negotiation Requirements, IETF MMUSIC working group, Work- 
in-progress, < draft-andreasen-mmusic-sdp-simcap-reqts-00. txt>. 

D. Kutscher et. al., Requirements for Session Description and Capability Negotiation, IETF Internet- 
Draft, Work-in-progress, <draft-kutscher--mmusic-sdpng-req-01 .txt>. 

H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP) ", IETF Request for Com- 
ments: 2326, April 1998. 

W. Marshall et. al., Integration of Resource Management and SIP -SIP Extensions for Resource Man- 
agement, IETF SIP working group, Work-in -progress, <draft-ietf-sip-manyfolks-resource-01 .txt>. 
Synchronized Multimedia Integration Language (SMIL) 1.0 Specification, W3C Recommendation, 
15-June-1998. 

N. Yeadon, F. Garcia, D. Hutchinson, D. Shepherd, Filters: QoS Support Mechanisms for Muttipeer 
Communications, IEEE Journal on Selected Areas in Communications, Vol. 14, No., 7, September 
1993. 



so [0005] The relevant prior art documents will now be acknowledged shortly: 

[0006] In W. Marshall et. al.: Integration of Resource Management and SIP - SIP Extensions for Resource Manage- 
ment, IETF SIP working group, Work-in-progress, <draft-ietf-sip-manyfolks-resource-01.txt>, the authors present a 
multi-phase call-setup mechanism that makes network QoS and security establishment a precondition to sessions 
initiated by the Session Initiation Protocol (SIP) and described by the Session Description Protocol (SDP). Network 

55 resources are reserved before the session is started using existing network resource reservation mechanisms (like 
RSVP). The resource management protocol is interleaved between two phases of call signaling and participants are 
invited after resources are available in the network. A confirmation of the preconditions is explicitly signaled. Resource 
management is done only for the network resources. An extension to SDP is introduced to determine whether the 
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preconditions are met. 

[0007] In G. Camarillo: Confirmation of SDP preconditions, IETF Internet Draft, Work-in-progress, <draft-camarillo- 
manyfolks-confirm-02.txt>, an additional direction attribute is introduced to indicate which party sends the confirmation 
of the preconditions. Finally, G. Camarillo: Confirmation of SDP preconditions, IETF Internet Draft, Work-in-progress, 
5 <draft-camarillo-manyfolks-confirm-02.txt> provides a mechanism to perform third party call control in SIP when SDP 
preconditions are used. 

[0008] In RFC 2533, A Syntax for Describing Media Feature Sets, Graham Klyne, 5GM/Content Technologies, March 
1 999 the authors present a format to express media feature sets that represent media handling capabilities. In addition, 
an algorithm is provided that matches the feature sets. It might be used to determine if the capabilities of a sender and 

to receiver are compatible. 

[0009] This matching algorithm is improved in G. Klyne (ed.): A revised media feature set matching algorithm, I ETF 
media feature registration WG, Work-in-progress, <draft-klyne-conneg-feature-match-02. txt>. 
[0010] In addition, G. Klyne (ed.): Identifying composite media features, IETF conneg working group, Work-in- 
progress, <draft-ietf-conneg-feature-hash-05.txt> describes an abbreviated format for composite media feature sets 

is that uses a hash of the feature representation to describe the composite. This can be used to provide an abbreviated 
form for referencing an arbitrary feature set expression, independent of any particular mechanism for dereferencing. 
In F. Andreasen, SDP Simple Capability Negotiation Requirements, IETF MMUSIC working group, Work-in-progress, 
< draft-andreasen-mmusic-sdp-simcap-reqts-OO.txt> the authors state the requirement that a capability set should con- 
tain a handle (similar to the hash mentioned above) allowing for easy referencing of the capability set. 

2° [001 1 ] In RFC 2703, Protocol-independent Content Negotiation Framework, Graham Klyne, 5GM/Content Technol- 
ogies, September 1999 the authors present an abstract framework for protocol independent content negotiation for 
the resources with which it interacts. It does however not provide the content negotiation process. It identifies the need 
for expressing the capabilities of the sender and the data resource to be transmitted, the capabilities of the receiver 
and the need for a protocol to exchange these capabilities. Negotiation is carried out by a series of negotiation metadata 

25 exchanges. Negotiation stops, if a specific data file has been found to be transmitted. The sender transfers the data if 
the sender determines the file, otherwise the receiver informs the sender. This proposal therefore relates to content 
negotiation. 

[0012] Work going on in D. Kutscher et. al.: Requirements for Session Description and Capability Negotiation, IETF 
Internet-Draft, Work-in-progress, < draft-kutscher-mmusic-sdpng-req-01.txt> identifies the requirements of a frame- 
so work dealing with session description and endpoint capability negotiation in multiparty multimedia conferencing sce- 
narios. Depending on user preferences, system capabilities or other constraints, different configurations can be chosen 
for the conference. The need of a negotiation process among the peers is identified, but not described, in order to 
determine a common set of potential configurations and to select one of the common configurations to be used for 
information exchange. This capability negotiation is used to get a valid session description compatible with the end 
35 system capabilities and user preferences of the potential participants. Different negotiation policies may be used to 
reflect different conference types. They also identify the need for network resource reservation coupled with session 
setup. Finally a proposal is drafted for describing capabilities and providing the negotiation language but not a protocol. 
[0013] The authors of F. Andreasen, SDP Simple Capability Negotiation, IETF MMUSIC working group, Work-in- 
progress, <draft-andreasen-mmusic-sdp-simcap-00.txt> propose a set of SDP extensions providing a minimal and 
^0 backward compatible capability negotiation mechanism. In B. Beser: Codec Capabilities Attribute for SDP, IETF Inter- 
net-Draft, Work-in-progress, <draft-beser-mmusic-capabilities-OO.txt> the author extends SDP so that end-points know 
the codec choices and can agree on a common set. The communication partner can thus obtain the originators capa- 
bilities and preferences. In J. Ott et. al.: Capability description for group cooperation, IETF Internet- Draft, Work-in- 
progress, <draft-ott-mmusic-cap-00.txt> a notation for describing potential and specific configurations of end systems 
^5 jn multiparty collaboration sessions is given. This enables mechanisms to define end system capabilities, calculate a 
set of common capabilities and to express a selected media description for use in session descriptions. They do not 
provide a protocol for capability exchange. In C. Bormann et. al.: Simple Conference Control Protocol, IETF Internet- 
Draft, Work-in-progress, <draft-ietf-mmusic-sccp-01.txt> the authors define services for a simple conference control 
protocol (SCCP) for tightly coupled conferences. Member management, application/session management and access 
50 control rules for distributed application resources are defined. The conference's state, which might be established using 
SIP, is managed during the lifetime using SCCP. This includes the finding of appropriate configurations, negotiating for 
configurations and changing the configuration. However, no interaction with local resource management is intended. 
[0014] The authors of K. Nahrstedt and J. M. Smith: The QoS Broker, IEEE Multimedia Magazine, Spring 1995 (2) 
1 , pp. 53-67 presented a model for an end-point architecture based on a QoS Broker, which is a functional entity that 
55 orchestrates resources at the end-points and coordinates resource management across layers. In order to configure 
the system properly, the broker uses admission control and negotiation. Negotiation among peer entities leads to a 
valid configuration, which involves all necessary components of the communication system. 
[0015] In the present document the term economy principle is used to describe the order of reservation described 
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in K. Nahrstedt and J. M. Smith: The QoS Broker, IEEE Multimedia Magazine, Spring 1 995 (2)1 , pp. 53-67: 

■ First, local resources are reserved. 

■ Then negotiation with the peer entity leads to a configuration that can be mapped to resource requirements at the 
5 peer, which are then reserved. 

■ Finally, reservation of network resources is done in the last step, because network resources are expensive and 
shared among multiple users. 

[0016] The authors of O. Levin, SIP Requirements for support of Multimedia and Video, IETF Internet-Draft, Work- 
10 in-progress, <draft-levin-sip-for-video-OO.txt> present a set of requirements for a call-control protocol for real-time mul- 
timedia support over IP. Capabilities have to be expressed, capabilities have to be signaled to identify the amount of 
resources that are necessary, and a call control mechanisms is needed to open/close/modify media streams within the 
boundaries set forth by capabilities and reserved resources. Also they propose to announce new capabilities (if avail- 
able) during a session. In addition, the peers have to agree on a common set of codecs to be used. A session control 
*5 mechanism to start/stop the streams is put as a requirement. 

[0017] In Bumess L. etal., The BRAIN Quality of Service Architecture for Adaptable Services with Mobility Support, 
in Proceedings of the PIMRC 2000, London, 2000; Kassler A. et al., BRENTA - Supporting Mobility and Quality of 
Service for Adaptable Multimedia Communication, in Proceedings of the 1ST Mobile Communications Summit 2000, 
Galway, Ireland, October 2000, pp. 403-408; and Kassler A. et al., An Open Endsystem Architecture for Adaptable 
20 Multimedia Services with QoS Support, in Proceedings of the BRAIN workshop, London, 2000, an end-system archi- 
tecture is presented that integrates local, peer and network resource reservation into a framework for end-to-end QoS 
management. User Preferences and adaptation paths are used together with QoS states to negotiate QoS at application 
level. Interaction with local resource management is introduced. The layered architecture provides support for different 
types of applications. 

25 [0018] The basic idea of extending existing session protocol layers, like SIP, for pre- negotiating Adaptation Paths at 
multiple levels of stream aggregations, is contained in European Patent Application 00 1 26 975.2, December 8, 2000. 
However, this European patent application does not detail a full-fledged End-to-End QoS Negotiation Protocol, and 
does not integrate admission control and resource reservation aspects. 

[0019] In the European Patent Application 00 11 1 1 91 .3, May 24, 2000, a data model detailing ways to achieve QoS 
30 synchronization and QoS correlation among multiple multimedia streams is presented. Such data model refines the 
concepts presented in the aforementioned European Patent Application 00 126 975.2. Such a data model, however, 
does not cover the description of capability like codecs. 

Problem to be solved by the invention 

35 

[0020] In [LevinOI], the author states on page 2: "(...) establishing a session of acertain quality, based on capabilities 
agreement during the session establishment and sustained throughout the duration of the session. The problem can 
be described as a lack of expressiveness in three following areas: capabilities specification, resource reservation and 
media stream control. 
40 [0021] The desired ultimate goal is 

- to express the capabilities (i.e. supported media, CODEC algorithms, bandwidth, etc.) without a need in configu- 
ration, 

- to signal the total resources required for a specific session (probably in terms of capabilities, and 

^5 - within a session, to explicitly open and close media streams and to modify the parameters of a certain stream 
within the boundaries of previously announced capabilities and reserved resources." 

[0022] The author also states on page 4: "SIP extensions may be needed to separate the 'capabilities announcement' 
phase from the actual opening of media streams." 
so [0023] In view of the prior art it is the objective of the present invention to propose a concept providing QoS guarantees 
in an effective manner. 

[0024] This objective is achieved my means of the features of the independent claims. The dependent claims develop 
further the central idea of the present invention. 

[0025] Further features, objects and advantages of the present invention will now be explained with reference to the 
55 figures of the enclosed drawings: 

Fig. 1 shows high-level MSC identifying phases, 
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Fig. 2 shows a functional decomposition of a structure to implement the present invention, 

Fig. 3 shows an example of a pre-negotiation phase 1 06 (MSC), 

5 Fig. 4 shows an example of a fast negotiation phase 108 (MSC), and 

Fig. 5 shows an example for the implementation of an E2ENP Broker in case of SIP implementation. 

[0026] Following are those requirements which can be of importance for providing QoS guarantees in an effective 
io manner: 

• Provision of a comprehensive set of mechanisms and protocols, linking together several aspects like: 

1 . Pre-Negotiation, which also can be done offline and published using e.g. LDAP 
'5 2. Negotiation integrated with ad-hoc reservation 

2.1 Economy principle 

2.2 Coordination of resource reservation, enhanced with the features listed below 

20 • Specific description of the interaction with local and peer resource management (some protocol procedures are 
required to this extent) 

• Use of state IDs to construct and reference an Adaptation Path 

• Explicit mention to hierarchical state machines for Adaptation Path at different levels 

25 [0027] One of the targets the invention is aiming at is the support of various types of services: 

• Conversational services 

• Distribution services 

• Information retrieval services 

30 

[0028] The concept proposed by the present invention can be adapted to these different types of services. The 
reason being that, depending on the type of service, different sequences of actions may be required for the interaction 
between reserving network and end system resources, which also depends on the communication mode of each peer 
(sender/receiver). 

35 [0029] For instance, questions need to be addressed, like whether a receiver needs to wait to be contacted by a 
sender, or who initiates resource reservation on the network (the sender or the receiver). The answers to these ques- 
tions depend on the type of service. 

The concept of an End-to-End Negotiation Protocol (E2ENP) 

40 

[0030] The establishment of a QoS-enabled communication session can be accomplished in a multi-step process, 
starting with negotiation of QoS aspects on an end-to-end basis. The idea hereby proposed is to have peers negotiating 
beforehand (i.e. before the actual communication takes place) a common level of QoS, the use of which peers can 
agree upon. This is a form of pre-negotiation of a vocabulary which peers can use later on for efficiently dealing with 
45 contingent negotiations (e.g. when establishing audio/video streams) or re-negotiations (changing the QoS Contract 
during ongoing sessions). The benefit of this approach is that the time necessary for re-negotiation is reduced because 
the peers have only to refer to a negotiated state instead of performing a full negotiation cycle during streaming. Fur- 
thermore, the type of negotiation can be tailored based on capabilities that are currently available at all peers. 
[0031] The identified steps are: 

so 

1 . Pre-negotiation of a set of QoS contracts with the peers. Such set describes an Adaptation Path for a generic 
stream of a given type (e.g. audio, video, or data streams). 

2. As an intermediate step, peers negotiate QoS correlation and synchronization aspects among multiple streams. 
55 This might not be necessary if a session contains only one stream: in that case QoS correlation would be simply 

ignored. Thus this step builds up the session concept. Note that, in case peers have to coordinate several streams, 
QoS correlation and synchronization issues would be handled at runtime by triggering specific coordination function 
(based on e.g. RTP), which are derived from the negotiated QoS states. 
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3. As a last step, peers negotiate QoS Contracts on a per stream basis at stream establishment time, based on 
the pre-negotiated vocabulary established during step (1). At this step, actual admission control is performed. To 
this extent, according to one aspect of the present invention it is proposed to follow an economy principle observing 
the fact that network resources have to be shared and are more expensive than local resources. The hereby 

5 proposed process is based on the steps in the following order: 

3.1 Local resources (i.e. resources managed by the local system) like CPU, memory, and power are reserved 
on the terminal device of the party initiating the communication (i.e. the initiator). These are the cheapest 
resources, since they are used exclusively by the initiator. The amount of resources that are reserved by the 

10 initiating party corresponds to the quality the initiator is most interested in and can cope with. 

3.2 Remote resources like CPU, memory, and power are reserved on the terminal device of the party accepting 
the request to establish the communication (i.e. the responder). These resources may be eventually shared 
by a plurality of initiators with respect to multiple telecommunication sessions, like In the case of a Video-on- 
Demand scenario (where the responder is the video server, which needs to serve multiple requests from 

75 multiple users). It does not make sense to try to reserve these shared resources (thus affecting other commu- 

nication sessions at the responder) prior of having ascertained the availability of resources at the initiator side. 

3.3 Only when both the local and remote resources have been successfully reserved, network resources are 
reserved which are shared (by definition) by a plurality of parties and therefore to this extent can be considered 
as the most expensive resources at all. 

20 

4. This invention describes a protocol procedure for informing peers about changes in capability configuration (e. 
g. the installation or removal of a given multimedia codec) of a given participant of the given communication session. 
By pro-actively disseminating this information among peers, proper actions can be taken with respect to any cur- 
rently active communication session, and to all the negotiation processes concerning future attempts to establish 

25 communication sessions. 

[0032] Steps (2) and (3) (or (1) 2 , (2), and (3)) can be treated jointly as one-shot 3 or separately as a sequence of 
actions 4 . 

[0033J Note that in certain cases only steps (3.1), (3.2) and (3.3) might be necessary. As an example this can be the 
30 case if everything is pre-negotiated by default (using fixed settings) and only one quality and configuration of a video 
stream is located on a server. 

[0034] A key aspect of the E2ENP is that it can be used not only in conjunction with network resource reservation 
signaling protocols, but also with other types of QoS architectures. In the latter case, pre-negotiation will focus on 
having peers agreeing on the types of QoS classes to use, with respect to the capabilities of each peer. 

35 

What to negotiate 

[0035] This section focuses on (i) what type of information (ii) under which circumstances needs to be negotiated. 
[0036] More specifically, peers should agree on: 

40 

• which E2ENP (or other protocol) to use; 

• which capabilities and configurations are available and applicable; 

• what QoS contracts are applicable and form the Adaptation Path; and 

• the Adaptation Paths themselves. 

45 

Types of supported E2ENP 

[0037] Most of the state of the art applications will not be able to employ the hereby-described E2ENP without any 
specific retrofitting. Rather they will eventually apply some other form of state of art negotiation mechanism. It is rea- 
so sonable to assume also that some future applications may eventually only partially support the E2ENP, or just different 
versions thereof. 

[0038] For these reasons, the first type of information that needs to be negotiated is the type and version of supported 
"E2ENP". 

[0039] This might be accomplished by using a directory server. As an example, a directory entry associated with a 

55 

o 

c In such a case, pre-negotlatlons might be no longer valid, should a new party join a session with a different understanding what an adaptation path 
is with respect to the already negotiated on. 

3 As an example, negotiation and set up of a session with two audio- and three video-streams, simultaneously 

4 Carry out the pre-negotiation first, then start with the first stream, add then the second stream, and so on. 
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given peer, and named E2ENP would act as a token indicating that the given peer supports the E2ENP. The directory 
entry could look like: 



E2ENP = ( type of service, protocol to be used, version) 



where "type of service" could indicate information retrieval service or conversational service, "protocol" could indicate 
SIP (together with SDP) or H.323 or RTSP (i.e. which protocol is the given E2ENP based upon), and "version" could 
be a number discriminating incremental sets of functionality. In addition to the aforementioned protocols, specific ex- 
tensions are needed to carry out the negotiation and describe the Adaptation Path. 

[0040] As an example, the E2ENP can be mapped - based on the type of service - to the following protocols: 



Type of Service 


Protocols 


Conversational services 


SIP(together with SDP)/H.323 + enhancements 


Distribution services 


SAP + RTSP + enhancements 


Audio/Video on Demand (Push/Pull) services 


RTSP + enhancements 



[0041 ] This information can be not only directly queried on purpose by the peers, but the directory servers themselves 
can also pro-actively disseminate it. 

Capabilities 

[0042] Various types of capabilities need to be negotiated among peers: 

• Media Types and QoS Contract Dimensions 

• Bitrates 

• Codecs 

• Terminal capabilities 

• Network Resource Reservation support 

[0043] The following paragraphs analyze in detail each type of capabilities. 
Media Types and QoS Contract Dimensions 

[0044] The type of media (audio/video/data) can be used for screening any piece of information in the E2ENP mes- 
sages. Peers agree on a common setoi media types. As an example, if a receiver requests to establish a live audio 
stream but the corresponding audio stream sender does not have a microphone, further negotiation of audio codecs 
is pointless and therefore it can be skipped . The use of media types thus translates in structuring the E2ENP messages 
in a format which is convenient for the peers while negotiating. In addition to media types, this invention identifies the 
need to include the list of QoS Contract Dimensions which the contracts are made of. As an example, one peer might 
want to negotiate frame-rate and frame-size, whereas other peers may want to negotiate frame-rate only. 
[0045] As an example, it might be useless to try to negotiate frame-size, if a VoD server has only one representation 
(version) of the movie available, and there is no network media adaptation unit available. 
[0046] This invention proposes the following format describing media type information: 



mediaType = (audio(param_audio), video(param_video)) 



[0047] The refinements "pararr^audio" and "param_video" detail the QoS contract dimensions, like frame-size, 
frame-rate for video and sampling frequency and number of channels for audio, and are described in the next sections. 
This format is to be applied to each media type description in a given E2ENP message. 
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Codecs 

[0048] Before peers can negotiate QoS Contracts or even Adaptation Paths (see below), they shall agree first on 
which codecs are generally applicable. The QoS achievable depends also on the type of codecs available. Furthermore, 
5 even though a given peer might be equipped with a given set of codecs, the use of such codecs is actually constrained 
by the availability of equivalent codecs by all the other peers. 

[0049] Today's SIP implementations allow the negotiation of codecs at invitation time on a peer-to-peer basis, and 
with respect to the specification of well-defined streams. 

[0050] In the framework of the present invention an extension of such a SIP capability is proposed, by negotiating 
10 during step (1) of the above cited steps (1) to (4) the complete list of available codecs, irrespective of which streams 
will be used later at stream establishment time. In other words, peers can in this way agree on a common subset of 
codecs before the actual media specification takes place. 

[0051] Furthermore, since current and future terminal devices shall be able to install or remove codecs "on the fly", 
the common set of codecs might need to be later re-negotiated during connection time (e.g. during a videoconference). 
15 The re-negotiation could be achieved by using new SIP messages. 

Bltrates 

[0052] Two main mechanisms are employed by clients to minimize the amount of bandwidth used for multimedia 
20 applications: 

• Using low (constant) bitrate codec thus reducing network resource consumption, 

• Using variable bitrate codecs 

25 [0053] Clients have to agree on a certain set of compatible codecs. It must, however, be assured that the bitrate the 
codec generates is supported both by the clients (for sending/receiving) and by the network (both the access networks 
and the core). In addition, one codec may generate different bitrate levels, which depend on the codec configuration. 
As an example, the G.726 codec may generate bitrates of 16, 24, 23 or 40 kb/s. There may be situations where the 
receiver is able to handle only a certain configuration of the given codec. As an example, if the receiver uses a 19.6 

30 kb/s modem, the receiver can only handle the 16 kb/s configuration of the G.726 codec. In addition, certain audio 
codecs and several video codecs can generate a variable bitrate, which is typically specified using a leaky bucket 
model. In this case the bitrate requirements are specified using a sustainable bitrate, a peak bitrate and a burst time 
(time duration that indicates how long the source is allowed to send at the peak rate). 

[0054] This invention proposes that in addition to a negotiation of the set of compatible codecs, for each codec the 
35 peers have to agree on a valid codec configuration in terms of bandwidth that each peer can handle. The initiator 
provides and negotiates a set of bandwidth specifications with the peers using the leaky bucket model (sustainable 
bitrate, peak bitrate, burst time), which supports both constant and variable bitrates. In the above example, both parties 
would agree on the G.726 codec with the following bitrate specification: (sustainable bitrate, peak bitrate, burst time) 
= (16, 16, N/A). 

40 [0055] Having agreed on a compatible codec configuration in terms of bitrates, actual target bitrates that are being 
used in the actual configuration are negotiated with the network during step (3). 

Terminal capabilities 

45 [0056] The physical characteristics (e.g. monitor size) of terminal devices may change from model to model, and 
affect the delivery of services over telecommunication networks. This is important, as it makes no sense for instance 
to stream a video in HDTV quality to a mobile phone, which is equipped with a much smaller display. Therefore, peers 
have to agree on terminal capabilities when negotiating QoS. Such terminal capabilities are e.g. the size of the display, 
the number of colors available, the general capabilities of rendering a given media type (e.g. if an audio mixer is 

50 available), and all kind of information for services that are necessary for rendering a given media type. 

[0057] To this extent, the Composite Capabilities/Preference Profiles [CC/PP] framework language (a combination 
of XML and RDF) and request/response HTTP protocol offer a handy way for specifying terminal capabilities in an 
RDF format. 

55 Network Resource Reservation support 

[0058] It is useless to try to demand network resources end-to-end using a signaling protocol like RSVP, if it can be 
determined a priori that one or multiple remote peers are not RSVP aware. To this extent, a possible solution is to ask 
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peers to check if a given signaling protocol is available at their access networks. 

[0059] A less complex solution is that, during pre-negotiation, peers indicate to each other along which direction they 
are going to reserve network resources. Allowable values are N/A, sender, receiver, senderf receiver, where the con- 
cepts of sender and receiver relate to the resource reservation protocol used (if any). This information can in fact model 

5 the type of reservation protocol used, if any. 

[0060] For instance, in a simple Video-on-Demand service scenario with RSVP available end-to-end, the client acts 
as a receiver, whereas the server acts as a sender, since RSVP is receiver-initiated. In case of YESSIR (see [Pan99] ), 
which is sender-initiated, the configuration - from a resource reservation protocol perspective - would be the opposite. 
[0061 ] Similarly, in a videoconference scenario with end-to-end RSVP support, each peer would be typically config- 

10 ured as a sender/receiver. 

[0062] If no direction is specified for a given peer, the corresponding peers can immediately deduce that no network 
resource reservation mechanism is available on the given peer. The key point is that this model allows to cope also 
with cases where no QoS signaling protocol (like RSVP) is available end-to-end. In such a case, each peer would be 
simply modeled as a sender (or nothing at all). This invention integrates the latter solution. 

15 

QoS Contract 

[0063] QoS Contracts are hereby defined as sets of high-level QoS characteristics, each expressed in terms of any 
of the following: 

20 

• Operating target: the desired value 

• Operating region: a desired interval of values 

• Thresholds/limits: a set of values marking different states with respect to the QoS adaptation business logic. 

25 [0064] Any of the aforementioned QoS specifications can eventually be furthermore expressed in a statistical format, 
by e.g. stating percentiles, mean value, variance, etc. 

Adaptation Path 

30 [0065] Peers can agree not only on a given QoS Contract, but also on alternative ones, which can be advantageously 
used whenever the network and/or terminal resources availability change over time. In such a way, each peer will 
exactly know which alternative QoS Contract (and under which circumstances) shall be enforced in order to cope with 
a critical QoS Change or with any QoS Violation with respect to the currently enforced QoS Contract. 
[0066] During the step (1) of the above-identified steps (1) to (4) only stream -related Adaptation Paths are pre- 

35 negotiated. Higher level ones (associated with QoS Correlation issues) shall be negotiated at higher level at step (2) 
of the above-identified steps (1) to (4). 

[0067] Together with the best-case QoS Contract, the Adaptation Path forms an extended QoS Contract. This ex- 
tended QoS Contract is negotiated and indexed. If a peer later decides to switch to a lower level of QoS, only the index 
identifying the QoS Contract as a state of a hierarchical Finite State Machine is needed to tell the other peer to adapt 
40 to that QoS State. 

Types of E2ENP 

[0068] The actors participating to communication sessions can act roles like: 

45 

• Sender/Receiver: the Sender can be solely transmitting data to a Receiver, whereas a Receiver receives data 
from a Sender. A two-way conference can be modeled with a Sender/Receiver and Receiver/Sender pair. 

• Initiator/Responder: the initiator invites responders to participate to a communication session. The responder waits 
for a request from the initiator. 

so 

Possible combinations are: 

• Initiator and Sender -> Responder and Receiver 

• Initiator and Receiver -» Responder and Sender 

55 

[0069] In the case where the Initiator is the Sender, the Sender of a media stream initiates the session (the Sender 
invites and the Receiver waits to be contacted). In the case where the Initiator is the Receiver, the Receiver of a media 
stream initiates the session (the Receiver invites and the Sender waits to be contacted). An Initiator/Sender can talk 



11 



EP 1 248 431 A1 



with a Responder/Receiver. An Initiator/Receiver can talk with a Responder/Sender. 

[0070] In the following the key scenarios affecting the type of E2ENP considered in this invention are listed. 

• Peer-to-Peer negotiation: Can be actually extended also to multiple peers participating to e.g. a videoconference, 
5 but where each peering is regulated by a direct peer-to-peer QoS negotiation mechanism. 

• 1xN Multicast negotiation: In this case, a sender and multiple receivers need to negotiate one or multiple QoS 
characteristics at a time. This can be done either on a connection-wide basis (i.e. determining a least common 
denominator good for all peers) or on a receiver-selected basis (peer-to-peer negotiation for some QoS charac- 

10 teristics among certain peers - see previous point). In case of a best effort level of agreement, receivers are still 

able to communicate even if they cannot agree on a least common QoS level, otherwise (e.g. in case of a guar- 
anteed QoS policy), those receivers must be dropped or other mechanisms have to be used. As an example, 
media filters or transcoders can be used in between a Sender and a Receiver to tailor media streams in such a 
way, that Receivers' capabilities and QoS states can be matched with Senders' QoS states. The media transcoder 

15 can be used to translate from one representation to another (e.g. switching the codec of the media stream from 

PCM to GSM audio). Media filters can be used for finer granular adaptation of media qualities (e.g. adapting to 
frame size, frame rate or desired quality without forcing the sender to adapt). 

[0071 ] The connection-wide E2ENP can be effectively used for enforcing QoS Correlation among multiple flows from 
20 various sources. The 1xN Multicast negotiation may be used for determining the common QoS not only for the case 
of a unique Sender transmitting to multiple Receivers, but also for the case of an unique Receiver correlating the QoS 
of incoming flows from many Senders. 

[0072] ITU-T Recommendation X.641 (12/97) ISO/IEC 13236:1998, Information technology-Quality of Service: 
Framework, describing the aforementioned types of negotiations, deals with 3-party negotiation, involving an Initiator, 

25 a Provider, and one or multiple Responders. In this invention we limit our scope however to the relationship between 
an Initiator and one or multiple Responders at application level. The choice of not directly involving explicitly Providers 
is due to the fact that Providers are only concerned with traffic and admission control. Therefore, only traffic contracts 
need to be negotiated between peers and the Network Providers, this can only be done during session establishment, 
as it does not make sense to reserve resources (especially network ones) for a given period of time in advance, i.e. 

30 without using them. 

[0073] Peers can therefore perform the hereby-described E2ENP pre-negotiation phase by agreeing upon nominal 
QoS levels. During actual connection establishment, peers then use the pre-negotiated contracts. These are tested 
locally, and resources are reserved. The result of this stage is then offered to the peers, and any excess resources are 
eventually released. Finally, at this level, network resources are reserved, which again may lead to release of excess 

35 resources. By monitoring the actual connection quality, peers can then decide at any time whether the given pre- 
negotiated QoS contracts are satisfied. And if not, whether and how to select an alternate QoS level, based on the 
pre-negotiated adaptation path. Provisions to avoid frequent requests to change network resource reservations are 
put in place by properly introducing tolerances and hysteresis in the QoS contracts and adaptation paths, as described 
in the European Patent Application 00 126 975.2 [MandaOOb]. 

40 [0074] In any case, during the pre-negotiation phase, each peer assesses the bids received from other peers against 
pre-configured User- Profiles, which contain pre-computed Adaptation Paths. The assessment can be achieved by 
comparing each parameter of each QoS Contract provided in the bid, with the corresponding information contained in 
the User Profiles, The decision whether to accept a bid or formulate a counteroffer is made with respect to all the QoS 
Dimensions of the bid QoS Contracts. Should the bid propose QoS Contracts with different QoS Dimensions, only the 

^5 subset of mutually understood QoS Dimensions would be taken into account. 

[0075] The initiator associates each QoS Contract of its bid with an identifier. Responders will notify the acceptance 
of a given QoS Contract (or the proposal for an update thereof, as a counteroffer), by specifying the corresponding 
identifier. Should a Responder feature a better QoS Contract resolution (like in the case of a given bid QoS Contract, 
in correspondence to which multiple QoS Contracts with "finer" granularity are available at one of the Responders), 

so said Responder may return a counteroffer with new QoS Contracts. It is up to the Initiator to collect these counteroffers, 
choose the most meaningful ones, associate them with new identifiers, and propose them to all peers in a new nego- 
tiation round. 

Mapping between Type of Service and Type of E2ENP 

55 

[0076] The following paragraphs describe how E2ENP can be deployed with respect to the various types of services 
mentioned above. 
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Conversational Services 

[0077] This is the case of services like real-time videoconference or CSCW. The key characteristic of these services 
is that the type of content exchanged among peers is most likely based on user interactions with the systems and with 

5 other peers. For instance, most of video flows will carry live images (e.g. taken from a web-cam). 

[0078] Another important aspect is that peers need to agree beforehand on a given agenda, which includes the start- 
time and duration of the service. This is typically accomplished by using SAP and SIP, in the Internet world. 
[0079] The manner how this type of services is actually deployed, is highly implementation dependent. Taking a 
videoconference as an example, special bridges are used in the telecom world so as to offer a star topology solution. 

10 Any interested party can thus join a videoconference by simply contacting the bridge. In the Internet world on the other 
hand, it is common the use of multicast technology: any interested party would simply have to "tune" on the proper 
multicast group. From an E2ENP perspective, however, we hereby assume that peers shall use unicast signaling for 
negotiating a common level of QoS. 

[0080] Conversational services can be modeled as cases of one Initiator and multiple Responders, where all peers 
15 can act as Sender and/or Receiver. Furthermore, from a resource reservation protocol, each party can use either a 
sender-driven or a receiver-driven network resource reservation protocol (if any). Thus, an initiator requests some 
resources from the network and from a Responder (since the Responder has to provide the resources for decoding 
and displaying). In addition, the Initiator manages its own resources locally. 

20 Distribution Services 

[0081] Distribution services can involve a content provider and (i) known or (ii) unknown content consumers. 
[0082] In the former case, SIP or RTSP extension might be used similarly to the case of information retrieval services 
(see below), in the latter case SAP extensions are hereby taken into account. The sender shall simply announce the 

25 list of multicast groups, which the receivers may choose from for "tuning" on the current content distribution. 

[0083] Except for the case of known content consumers, only a reduced version of E2ENP can be mapped to SAP. 
The Adaptation Path can be simply modeled as having the content provider streaming the same content with different 
QoS levels to different multicast groups (one per QoS level). Content consumers shall therefore simply monitor the 
level of QoS available at their terminal/access network, and eventually tune on another multicast group if any QoS 

30 Change or QoS Violation occurs in the meanwhile. Alternatively, the full-blown E2ENP could be used in conjunction 
with media filter/transcoder in the network, tailoring the media streams to match the different QoS levels. To this extent, 
the content consumers should simply instruct the media transcoders/filters to switch to a new QoS level. It is up to the 
Content Provider and to the Receivers to ensure that the streams distributed on different multicast groups are mutually 
synchronized. 

35 [0084] For optimization purposes, the sender may however collect statistics concerning the number of receivers per 
multicast group (channel), so as to avoid flooding the network with packets of unused channels. This requires signaling 
between the Content Provider and each Receiver. This invention however does not address such cases. 

information Retrieval Services 

40 

[0085] This type of services is typically managed by using RTSP protocol. This invention proposes enhancements 
of such protocol for achieving E2ENP goals, similarly to what described for the case of conversational services. More 
specifically, one has to note that the RTSP process is initiated by the receivers by requesting the sender to describe 
a given media (e.g. a video stream) through the RTSP DESCRIBE method. Through this method, a receiver gets 

45 informed about the various levels of QoS, which the sender may enforce for playing out the given media. The receiver 
has thus the possibility to choose which level to enforce at any given time. This is a form of pre-negotiation process 
paired with a fast negotiation cycle, similar to the concept presented by this invention. The key idea is to enhance the 
TRSP DESCRIBE method to include all the information about capabilities described above, and to integrate RTSP 
with the hereby-presented distributed resource management mechanism. 

so [0086] QoS Correlation features can also be achieved by using SMIL [SMIL98]. This invention does not address the 
integration of such technology. 

End-to-End Re-Negotiation Protocol (E2ERP) 

55 [0087] The E2ERP is the subset of the E2ENP focusing on re-negotiation issues. This protocol is activated whenever: 

1 . QoS Violations have been detected at functional entity involved in the transmission process; or 

2. the current monitored level of QoS is no longer compatible with the currently enforced QoS Contract; or 
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3. a notification of newly discovered additional resources has been received by some specific functionality; or 

4. one of the peers decided to enforce a different QoS Contract (e.g. the user requested a higher frame-rate). 

[0088J Cases 2 and 3 are mostly related to optimization processes, which allow applications to upgrade/degrade 
5 their QoS requirements in a smooth manner, whereas case 1 deals with dramatic shortages of resources, which badly 
affect applications, if not properly and promptly treated. 

[0089] To this extent, case 1 implies re-negotiating local and eventually network resources without the need to try to 
maintain the previously reserved resources, whereas this is not possible in cases 2 and 3. This means that whenever 
dealing with optimization issues, one has to take care of: 

10 

• either allocating resources in excess of the difference between the previously allocated resources and the new 
amount (in the case of QoS upgrade); 

• or allocating the new resources from the scratch, while keeping the old ones until the re-negotiation has been 
successfully completed (pessimistic approach). This can also be modeled as trying to allocate more resources 

15 while still keeping the old one. If this re-allocation fails, the originally reserved resources are still reserved, otherwise 

the newly allocated resources are available; 

• releasing some resources to switch to a lower QoS state (in the case of QoS downgrade). 

[0090] The first option seems to be quite attractive, but some resources might not be easily shared among different 
20 QoS States. For example, the scheduling information about the thread of a given codec might be totally useless, if the 
codec is going to be pre-empted and substituted with another one, which runs on a totally different thread. 
[0091] Therefore the second approach, though pessimistic, seems to be the most realistic one. In the following we 
will therefore refer explicitly to the allocation of new resources and later release of old ones. In addition, releasing 
resources is always possible, because the system load is decreased. 
25 [0092] Whenever a re-negotiation is triggered, each peer determines from the pre-negotiated Adaptation Path the 
best alternative QoS Contract that should be enforced in order to cope with the detected QoS Change/Violation. The 
identity of the new QoS Contract is exchanged among peers, in order to come to an agreement on which QoS Contract 
should be actually enforced. Having previously negotiated the Adaptation Path allows the peers to more efficiently 
perform such re-negotiating, by simply exchanging identifiers. Should all peers detect a violation simultaneously, some 
30 form of contention resolution algorithm would need to be enforced. To this extent different well-known techniques are 
available: assigning master/slave roles (typically assigning to the Initiator the master role), or re-attempting after a 
random time has elapsed. This invention leverages the master/slave mechanism. 
[0093] in summary, the following types of re-negotiation are identified: 

35 a) re-negotiation-triggered by a QoS violation detection, where new resources are allocated from the scratch and 

the old resources are automatically released (for QoS downgrade cases, this might be not an issue); 

b) re-negotiation for optimizing the system, where new resources are allocated from scratch and the old resources 
are released later, at E2ERP successful completion; and 

c) re-negotiation for optimizing the system, where new resources are allocated from scratch and the old resources 
^0 are automatically released. 

A framework for dynamic end-to-end QoS negotiation and control 

[0094] This invention presents a framework for achieving dynamic end-to-end QoS negotiation and control coordi- 
^5 nation, for distributed multimedia applications. The framework builds upon dynamic capability negotiation and specifi- 
cation of Adaptation Paths and QoS Contracts, based on user preferences. These principles will now be explained 
with reference to the figures. 

[0095] The Initiator 101 finds the protocol version using a Protocol Discovery Unit 104, 213 via interface 214, which 
queries a Directory Server 102, 215. This is coordinated with the local Coordination Unit 204. The Session Protocol 

so Unit 205 is used for all kind of negotiations and communication. In particular it negotiates with the Peer 21 6 (which is 
the Responder 1 03) a common set of capabilities and configurations and thus builds a vocabulary in the Pre-Negotiation 
phase 106. It also negotiates QoS Contracts and Adaptation Paths that are used for the Multi-Stream QoS synchro- 
nization and QoS correlation phase 107. Local Resource management is carried out by the Local Resource Manage- 
ment Units (responsible for CPU, buffer and other local resources) 206 via interface 211. Local Resource management 

55 is coordinated by the Coordination Unit 204 with network resource reservation, which is carried out by the Network 
Resource Reservation Unit 207, via interface 212. 

[0096] Any end-to-end interaction during communication session establishment, i.e. during the Fast Negotiation 
phase 1 08, is carried out by following the Economy Principle. This principle states that first local, then peer and finally 
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network resources are reserved. If during the communication session a re-negotiation is necessary due to a change 
in resource availability or to any other reasons influencing resource availability, the Re-Negotiation phase 1 09 is carried 
out by following the Economy Principle as well. 

[0097] Finally, resource reservations release is done during the Release phase 110. The local Protocol Stack 208 

5 interfaces with the Session Protocol Unit 205 via the interface 217 and implements the session protocol. In addition, 
the Protocol Stack 208 implements the network resource reservation protocol which is controlled via interface 210. 
[0098] The QoS-Aware Application Unit 202 uses a FSM Engine Unit 203 to control the states of all the streams that 
the QoS-Aware Application Unit 202 handles. The Coordination Unit 204 together with FSM Engine Unit via interface 
209 provides the QoS-Aware Application Units 202 with the possibility to establish, use, control and release network 

10 connections with other applications, using QoS guarantees. Establishing such connections involves negotiation of 
capabilities, configurations, QoS Contracts and Adaptation Paths (managed by the FSM Engine Unit 203), and inte- 
gration of local, peer, and network resources according to the Economy Principle. Control involves re-negotiation and 
integration of local, peer, and network resources and may involve a state transition managed by the FSM Engine Unit 
203, in cooperation with the Coordination Unit 204. Release involves network and local, as well as peer resource tear- 

15 down and state management (by the FSM Engine Unit 203), in cooperation with the Coordination Unit 204. 

[0099] This invention also presents the concept of the E2ENP Broker 1 05, an optional third-party entity, which can 
be used for relieving peers 101, 103 from performing the time-and resource-consuming Pre-Negotiation phase 106 
(and eventually also the Multi-Stream QoS Synchronization and QoS Correlation 107). Each peer 101, 103, after dis- 
covering from a Directory Server 1 02 which E2ENP Broker 1 05 to contact, can upload its Adaptation Path, Capabilities, 

20 and the list of peers to contact on said E2ENP Broker 105. The E2ENP Broker 105 may be implemented e.g. as an 
enhanced version of audio-/videoconference bridges, or by combining an enhanced SIP proxy server (or SIP redirect 
server) - dealing with the negotiation process - and an enhanced version of a SIP registrar - storing the Adaptation 
Path and Capabilities and all the intermediate negotiated versions thereof. 

[01 00] The E2ENP Broker 1 05 thus collects such information from each peer 101,1 03, and performs the negotiation 
25 process locally in its memory space. During this process, the E2ENP Broker 1 05 may eventually contact some of the 
indicated responders 103 on behalf of the initiator(s) 101 , should such responders 103 do not have yet stored their 
information on said E2ENP Broker 105. Once the negotiation has been carried out successfully, the E2ENP Broker 
1 05 will notify the peers 1 01 , 1 03 about the availability of the results, and each peer 1 01 , 1 03 can then download said 
results. The E2ENP Broker 105 can also allow multiple negotiation iterations (otherwise too expensive to be carried 
so out among peers themselves). Responders 1 03 might disagree with a bid from the Initiator 1 01 , and therefore provide 
counteroffers. The analysis of counteroffers involves multiple round-trip message exchanges among peers, and there- 
fore is too time consuming. The E2ENP Broker 105 can mediate all this process. 

Example 

35 

[0101] The example in this section is illustrating the concepts of our invention. It is based on a real-time multimedia 
conferencing scenario using IP-based networks. Media transport is carried out by using RTP/RTCP. 
[0102] For simplicity reasons, we are showing the invention's principle using a pseudo-protocol (QUERY, RE- 
SPONSE, COMMIT, START, START_ACK, RESERVE, CONFIRM) which can be mapped onto existing SIP/SDP plus 
40 extensions to be standardized. Also, this example is restricted to two peers A and B. Let us assume that the Initiator 
101 wants to receive a media stream (let us assume video) from the Responder 1 03. 

[0103] The E2ENP process starts with the Pre-Negotiation phase 106 assuming that the Protocol Discovery 104 has 
successfully been completed earlier, figuring out a common E2ENP version that both parties understand. 
[0104] In the Pre-Negotiation phase 1 06, the QoS-Aware Application Unit 202 requests a negotiation using the local 
^5 FSM Engine Unit 203, providing a bid. This bid contains a list of capabilities and configurations as well as QoS Contracts 
and the Adaptation Path(s), which are all indexed. The description of the bid can be realized using SDP extensions 
(e.g. as a new feature of the currently investigated SDPng [DPNG00]). 

[0105] The Coordination Unit 204 forwards the bid via the session protocol unit 205 to the peer using the QUERY 
message, which can be based on SIP extensions. The peer's Session Protocol Unit 205 receives the QUERY and asks 

so the Peer Coordinator 204 to evaluate the bid using the Peer FSM 203. The Peer FSM matches the bid with its own 
adaptation path and capabilities and generates a common subset, which is forwarded in the Response massage via 
the Peer Coordinator 204 to the Peer Session Protocol Unit 205, which generates a RESPONSE message which can 
be based on SIP extensions. The initiator's Session Protocol Unit 205 upon reception of the new bid forwards an 
evaluate request to the local FSM 203 via the Coordinator 204. Finally, the new bid is again checked for compatibility 

55 (it might be empty indicating that the peers are incompatible) and the Initiator's (101) FSM Engine 203 collects all the 
new bids from all responders and generates a common subset, which is sent to all peers. This is done by first sending 
an enforce message to 204, which forwards it to 205. The initiator's Session Protocol Unit 205 generates the commit 
message, which can be based on SIP extensions. This message carries the bid-match result (which can be described 
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using SDP extensions). This is distributed to the session protocol unit 205 of the responder 103, which enforces the 
result via the Coordination Unit 204 to the FSM 203. At this point, all communication partners have agreed on a common 
set of codecs, capabilities, adaptation paths and QoS states and are able to decode later on the references (denoted 
as StatelDs). 

5 [0106] The assumption which shall be made now is that the initiator 101 wants to initiate the actual session, which 
contains one video stream. The states and adaptation paths have been negotiated during the pre-negotiation phase 
106 just described. The QoS-Aware Application Unit 202 of the Initiator 101 requests a start of the stream given a 
StreamID and its desired StatelD from the local Coordinator Unit 204, which first performs local admission tests and 
reserves the resources locally requesting the resources from the Local Resource Management Units 206. If the desired 

10 state cannot be fulfilled due to local resource problems, the Coordinator Unit 204 would request the FSM Engine 203 
to try the next QoS State having lower resource requirements according to the negotiated Adaptation Path. After local 
successful resource reservation, the start request is propagated to the local Session Protocol Unit 205, which sends 
a START message to the peer's Session Protocol Unit 205 message, which can be based on SIP extensions. This 
message contains the enforced StatelD and Stream ID (which both can be modeled by using SDP extensions. The 

is start message is forwarded via the peers Coordinator Unit 204 to the peers FSM Engine Unit 203, which checks for a 
valid StatelD. If this is approved, the FSM Engine Unit 203 requests resources for handling the media streams using 
the Coordination Unit 204 and the services provided by the Local Resource Management Units 206, which perform 
admission tests and reserve the resources at the peer. 

[0107] Note that if the resources at the peer cannot be granted, the peer Coordination Unit 204 requests the FSM 

20 Engine Unit 203 to select a new StatelD according to the pre-negotiated Adaptation Path. If everything is approved, 
the peer Coordination Unit 204 requests the peer Session Protocol Unit 205 to send an START.ACK to the Initiator's 
1 01 Session Protocol Unit 205 with the new StatelD, which is forwarded via the local Coordination Unit 204 to the local 
FSM Engine Unit 203. The local FSM Engine Unit 203 checks for compatibility of the states and, if approved tells the 
local Coordination Unit 204 to request reservation of network resources (e.g. using RSVP) via the local Network Re- 

25 source Reservation Unit 207. If the StatelD were different from the originally selected one, it would instruct the Local 
Resource Management Units 206 to update the local resource reservation according to the new StatelD (which is not 
shown in Fig. 2, because we assumed that everything was fine). Additionally, the Coordination Unit 204 may request 
the Session Protocol Unit 205 to send a RESERVE message to the peer 103, should that peer be responsible to 
manage network resource reservation within the access networks they are attached to [MarshOO]. In such a case, upon 

50 reception of the RESERVE message through its Session Protocol Unit 205, the peer 1 03 would trigger its Coordination 
Unit 204 to request network resources via the peer's Network Resource Reservation Unit 207 (e.g. using RSVP). Once 
resources have been reserved at the network level, the Coordination Unit 204 at the peer 216 sends a confirmation 
back to the sender using the CONFIRM message, which is received by the local Session Protocol Unit 205. This unit 
generates a confirmation to the local Coordination Unit 204. Once the Initiator 101 has collected all the confirmations 

35 from all the Responders 103, it releases the role of the Initiator 101 and everything is setup properly. 

[0108] For performing concurrency control, anybody starting a Pre-Negotiation phase 106, Multi-Stream QoS Syn- 
chronization and QoS Correlation phase 107, Fast negotiation phase 108, or Re-Negotiation phase 109 can take the 
role of Initiator 101 . Therefore it will start sending messages to known peers inviting them to participate in the given 
phase. If none of the other peers is acting as Initiator 101, Peer 216 realizes it is acting as an Initiator 101 and waits 

40 confirmation of resource reservation (aggregate local and network) from Peers acting as Responders 1 03. Otherwise, 
if one of the Peers 21 6 is already acting as Initiator 101, said Initiator 1 01 will add the prospecting Peer 21 6 to its list 
of Responders 1 03, and the prospecting Peer 21 6 will wait to get invited by said Initiator 101. 
[0109] Once the given phase is over, i.e. once the given Initiator 101 has collected all the confirmations from all the 
Responders 103, the given peer acting as Initiator 101 "releases" the role of initiator. In this mode a token passing 

^5 mechanism is used, where the acquisition of the token grants the role of Initiator 101 and the passing is done once a 
phase is completed. In this way also the case of collisions is covered by using a master-slave approach, where the 
master is the Initiator 101 and the slave is the Responder 103. The Initiator 101 commands the Responder 1 03 when 
to start network reservation. In any case, network reservation would be carried out concurrently among peers (except 
for the case of a QoS reservation signaling protocol - like RSVP - where available end-to-end). 

50 

Aspects of the present invention 

[0110] Now the different concepts proposed by the present invention will be explained: 

55 m Integration and extensions of different existing protocols and technologies for defining the E2ENP (including 
E2ERP): More specifically, this aspect encompasses the following phases: Protocol Discovery 104, Pre-Negotia- 
tion 106, Multi-Stream QoS Synchronization and QoS Correlation 107, Fast-Negotiation (with Economy Principle) 
108, Re-Negotiation (with Economy Principle) 109, Resource Reservation Release 110. All the six phases can be 
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concatenated, or be executed at different times. The Multi-Stream QoS Synchronization and QoS Correlation 1 07 
phase is optional, insofar as it is required only if Peers 216 interact by sending/receiving multiple streams, which 
need to be correlated and synchronized. The Protocol Discovery 104 and P re-Negotiation 106 phases can be 
executed a priori, and the results can then be applied to multiple successive communication sessions, whereby 

5 each communication session is initiated with a specific Multi-Stream QoS Synchronization and QoS Correlation 

phase 107. Should even the results of the latter phase be applicable to multiple successive communication ses- 
sions, each of said communication sessions can be initiated with a specific Fast Negotiation phase 108. The 
protocol interacts with the Local resource management units 206 during Pre-Negotiation 106, Multi-Stream QoS 
Synchronization and QoS Correlation 107, Fast Negotiation 108, Re-Negotiation 109 and Resource Release 110 

10 phases. 

■ Economy Principle: According to this aspect, the resource admission control and resource reservation can be 
applied following this order: On the E2ENP Initiator 101 first, then on the E2ENP Responder(s) 1 03, and finally on 
the network using 207. In the first two steps, issues like real-time CPU scheduling, memory management, and 

15 power management are addressed. The same process applies in case of re-negotiations, with the difference that 

previous allocated local resources need to be updated (either released or re-allocated) either immediately or later 
during the Resource Reservation Release 110 phase. For the Resource Reservation Release 110 phase, first 
network resources, then peer, and finally local resources are released, 

20 m Concept of E2ERR. According tot his aspect, during runtime of a so established multimedia session, at any time 
any component may request an adaptation. This again requires coordination of local, peer and network resource 
management, according to the Economy Principle. When performing this adaptation, user-defined or user-provided 
preferences can be used implicitly in order to build the Adaptation Path. 

25 m Pre-negotiation of type of E2ENP:Th\s can be done during Protocol Discovery phase 1 04, either by forcing peers 
1 01 , 1 03 to query a Directory Server 1 02, or by having the latter announcing such information. Instead of a directory 
server, a SIP registry server can also be used. 

■ Pre-negotiation of capabilities: This can be done during Pre-Negotiation phase 1 06, by using specific protocol, e. 
30 g, SIP/SDP plus extensions. 

■ Pre-negotiation of complete codec list: This can be done during Pre-Negotiation phase 106, by using specific 
protocol, e.g. SIP/SDP plus extensions. 

35 ■ Pre-negotiation of Adaptation Paths at stream levei:Th\s can be done during Pre-Negotiation phase 106, by using 
specific protocol, e.g. SIP/SDP plus extensions. 

■ Pre-negotiation of Adaptation Paths at stream aggregation level: This can be done during Multi-Stream QoS Syn- 
chronization and QoS Correlation phase 107, e.g. SIP/SDP plus extensions. 

40 

■ Indexing of pre-negotiated QoS Contracts and Capabilities for speeding up the Fast Negotiation phase 1 08. 

■ Indexing of pre-negotiated QoS Contracts and Capabilities for speeding up the Re-Negotiation phase 1 09. 

« ■ Modeling the data model, described in EPA 00 126 975.2, in an extended version of either SDP orSDPnG. Handling 
installation/de-installation of Capabilities even at runtime, by exchanging asynchronous messages among peers 
for notifying such events. This can be based on e.g. SIP/SDP plus extensions. 

■ Support of a E2ENP Broker 105: this is an optional third-party entity, which can be used for relieving peers 1 01 , 
50 1 03 from performing time- and resource-consuming Pre-Negotiation phase 106 (and eventually also the Multi- 
Stream QoS Synchronization and QoS Correlation 107). Each peer 101 , 103, after discovering from a Directory 
Server 102 which E2ENP Broker 105 to contact, can upload its Adaptation Path, and the list of peers to contact 
on said E2ENP Broker 105. The E2ENP Broker 105 may be implemented e.g. as an enhanced version of audio-/ 
videoconference bridges, or by combining an enhanced SIP proxy server (or SIP redirect server) - dealing with 

55 the negotiation process - and an enhanced version of a SIP registrar- storing the Adaptation Path and Capabilities 

and all the intermediate negotiated versions thereof. The E2ENP Broker 105 thus collects such information from 
each peers 101, 103, and performs the negotiation process locally in its memory space. During this process, the 
E2ENP Broker 1 05 may eventually contact some of the indicated responders 1 03 on behalf of the initiator(s) 1 01 , 
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should such responders 1 03 do not have stored their information on said E2EN P Broker 1 05. Once the negotiation 
has been carried out successfully, the E2ENP Broker 105 will notify the peers 101 , 103 about the availability of 
the results, and each peer can then download the results. 

5 ■ Use of E2ENP Broker 1 05 to allow multiple negotiation iterations, which would otherwise be too expensive. Re- 
sponders 1 03 may disagree with a bid from the Initiator 1 01 , and therefore provide counteroffers. The analysis of 
counteroffers involves multiple round-trip messaging among peers, and therefore is too time consuming. The 
E2ENP Broker 105 can mediate and speed up the given process. 

to ■ Extension of SIP and RTSP for Pre- Negotiation 106 of Adaptation Path (at stream level) and Capabilities, by 
piggybacking this information in existing messages of SIP or RTSP. 

■ Extension of SIP and RTSPior Pre-Negotiation of Adaptation Path at stream aggregation level 1 07, by piggyback- 
ing this information in existing SIP or RTSP messages (according to EPA 00 111 191 .3). 

15 

■ Protocol procedures and messages for addressing Fast Negotiation 1 08 and Re-Negotiation 1 09 phases (by using 
the identifiers associated with the pre-negotiated QoS Contracts of the Adaptation Path). 

■ Extension of SIP/SDP and RTSP, by defining messages for addressing: 

20 

a. QoS Contract negotiation; 

b. coordination of network resource reservation (if any) among peers. 

■ Extension of SIP and RTSP lor Fast Negotiation 108, by using indexed QoS Contracts and Capabilities. 

25 

■ Extension of SIP and RTSP for Re- Negotiation 109, by using indexed QoS Contracts and Capabilities. 

■ Coordination of network resource reservation mechanisms among peers, according to the Economy Principle, by 
introducing acknowledged synchronization procedures in SIP and RTSP during Fast Negotiation 108 and Re-Ne- 

30 gotiation 109 phases. 

■ Extension of SAP tor allowing Directory Servers 105 announcing types of end-to-end QoS negotiation protocols 
used. 

35 ■ Extension of existing directory protocols or of SIP with respect to the use of SIP Registrars, in order to store and/ 
or retrieve types of end-to-end QoS negotiation protocols used for enabling the Protocol Discovery Phase 104. 

■ Extension of SAP for announcing Adaptation Paths with respect to Distribution Services, where AP are simply 
listing various multicast groups, each targeting a specific QoS Contract. 

40 

■ Ail the E2ENP-related changes to SIP can theoretically be mapped onto H.323 as well. 

■ Management of resource reservation release 1 1 0 

45 ■ The negotiation and re-negotiation of capabilities - during, respectively, the Fast-negotiation (with Ecoomy princi- 
ple) phase 108 and the re-negotiation (with Economy principle) phase 109 - include the signaling that the peers 
216 need to exchange with each other, in order to agree on the choice of audio and/or video codec and the con- 
figuration thereof (bitrate etc.) 

50 Embodiment for the Implementation of the present invention: 

[0111] Now an embodiment for the implementation of the present invention will be explained with reference to Fig. 2: 
[01 1 2] Each Peer 21 6 consists of a Computing Unit 201 containing a Protocol Stack 208 (e.g. IP and TCP/UDP) and 
a Coordination Unit 204. The Coordination Unit 204 coordinates: 

55 

1 . Protocol Discovery phase 104 through interface 214 to Protocol Discovery Unit 213; 

2. Pre-Negotiation phase 106 and Multi-Stream QoS Synchronization and Correlation 107 through interface 209 
to FSM Engine Unit 203, and through interface 21 0 to Session Protocol Unit 205; 
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3. Fast Negotiation phase 108 through Interface 211 to Local Resource Management Units 206, through interface 
210 to Session Protocol Unit 205, and through interface 212 to Network Resource Reservation Unit 207; 

4. Re-Negotiation phase 109 through interface 209 to FSM Engine Unit 203 (for evaluating alternative QoS Con- 
tracts by using the Adaptation Path), through interface 211 to Local Resource Management Units 206, through 
interface 210 to Session Protocol Unit 205, and through interface 212 to Network Resource Reservation Unit 207; 

5. Release phase 110 through interface 211 to Local Resource Management Units 206, through interface 210 to 
Session Protocol Unit 205, and through interface 212 to Network Resource Reservation Unit 207. 

[0113] A FSM Engine Unit 203 can be part of a given QoS-Aware Application Unit 202, or can be a separate entity 
(middleware), which multiple given QoS-Aware Application Units 202 can use. The FSM Engine Unit 203 is a software 
process that, after having been configured with a given Adaptation Path , is capable of implementing the FSM associated 
with the given Adaptation Path, on behalf of the QoS-Aware Application Unit 202, in cooperation with the Coordination 
Unit 204. 

[0114] A Protocol Discovery Unit 213 allows the Coordination Unit 204 contacting a Directory Server 215 (which 
might also be implemented as an extension of a SIP Registrar), in order to accomplish the Protocol Discovery phase 
1 04. The Protocol Discovery Unit 21 3 extends the use of existing specific protocols (e.g. LDAP, SAP, SIP), by advertising 
and querying information about E2ENP, on behalf of the Coordination Unit 204. 

[0115] A Session Protocol Unit 205 allows the Coordination Unit 204 carrying out the phases 106-110 with Peers 
21 6. The Session Protocol Unit 205 extends current protocols like SIP/SDP or RTSP (or even H.323/H.245), by using 
SDP or SDPnG enhancements for describing bids/counteroffers for Adaptation Path and Capabilities, and by introduc- 
ing SIP or RTSP (or even H.323/H.245) specific messages for implementing the signaling required for the phases 106 
to 110, especially for the Pre-Negotiation phase 1 06 and the Multi-Stream QoS Synchronization and Correlation phase 
107 (including the resource coordination according to the Economy Principle). 

[01 1 6] Interfaces 21 1 to the Local Resource Management Units 206 are identified with respect to the following classes 
of resources: 

CPU resources 

Memory (primary and secondary) resources 
Battery power 

External auxiliary resources 

[0117] For each class of resources, a specific Local Resource Management Units 206 is made available, e.g. as an 

extension of the Operating System loaded onto the Computing Device 201 . 

[0118] The interfaces 211 allow the Coordination Unit 204 to carry out the following tasks: 

Monitor resource usage, according to various criteria (e.g. ordered per stream or per process) 

- Register (and de-register) for notifications to be forwarded to the Coordination Unit 204 once and/or anytime a 
given condition is met 

- Reserve (and release) a given amount of resources (by e.g. setting a CPU deadline or pinning a memory area to 
a given process) 

Update a given reservation (for the re-negotiate case) 

Associate (and de-associate) a given entity, e.g. a process, to a class of local resources usage (this is typically 
done for those resources that cannot be directly manipulate without OS supervision). The class is a kind of priority, 
which the OS can use for optimizing resource usage according to the user's policies. 

[0119] Each Peer 21 6 can take the role of Initiator 101 , provided that all other peers are not acting as Initiator 101 
in the meanwhile. The role is maintained for the whole duration of any of the following phases: 

Pre-Negotiation 106, 

Multi-Stream QoS Synchronization and QoS Correlation 1 07, 

- Fast-Negotiation (with Economy Principle) 108, and 
Re-Negotiation (with Economy Principle) 109. 

[0120] During the Resource Release phase 110, some of the peers not involved in the session tear down process - 
and thus willing to continue the session with any remaining peer - may also take the role of the Initiator 101 in a 
concurrent phase 107, 108 or 109. 

[0121] Should a Peer 216 (thereinafter the peer A) try to act as an Initiator 101 and invite other Peers 216 to act as 
Responders 103 for one of the aforementioned phases, while said phase is ongoing (i.e. while one of the other Peers 
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21 6 is already acting as an Initiator 1 01), the peer A would be notified that it needs to wait an invitation from the currently 
active Initiator 1 01 , and the latter would have to add peer A to its list of Responders 1 03. 

[0122] The conclusion of any of the aforementioned phases coincides with the collection at Initiator 101 side of all 
the confirmations of successfully reserved network resources from all the Responders 103. The Initiator 101 has to 
5 validate each confirmation against to all the others already received, in order to eventually rebalance the use of re- 
sources among peers, by taking corrective actions. 

[0123] Once the conclusion has been reached, the Peer21 6 acting as Initiator enters in a neutral state, thus releasing 
the role of Initiator 103 to any prospective Peer 216. The role of Initiator 103 can be thus modeled as a logical token 
(the Initiator Role Token IRT), which can be exchanged among peers once any of the aforementioned phases is over. 

10 [0124] Other Peers 216 can join an already active communication session among multiple Peers 216. Is it really 
necessary and/or feasible in these cases to re-negotiate everything? One key point of this invention is the de-coupling 
of the Pre-Negotiation 1 06 phase from the actual Multi-Stream QoS Synchronization and QoS Correlation 1 07, Fast-Ne- 
gotiation (with Economy Principle) 108, and Re-Negotiation (with Economy Principle) 109 phases. As long as Peers 
216 agree beforehand, at session advertisement time, on what level of QoS to use, they can then join (or leave) an 

'5 active session anytime, by using the fast indexed negotiation process described in this invention. The key problem, 
however, is how to deal with Peers 21 6 joining the conference at a later time, without having pre-negotiated anything. 
In this case, several options are available: 

1 . To re-negotiate everything from scratch among all Peers 216 - this is an unfeasible solution, not only because 
20 of the service disruption with high latency, but also because this solution would enforce dependencies among the 

connections belonging to e.g. a videoconference session, which is unrealistic in most of the cases. 

2. To force the new Peers 21 6 to accept the already pre-negotiated information: If a new Peer 21 6 does not accept 
this, he/she can not join the given session. 

3. To enforce media adaptation through some filters embedded into the network, to meet the other preferences of 
25 the new Peer 21 6. More details on this concept can be found in [Pasqu92], [Pasqu93], [Yeado93], [Kassl99a] and 

[Kassl99b], 

[0125] As a conclusion, this invention assumes that either solution 2 or 3 is enforced by any application enabled to 
handle these issues (e.g. a conference control tool), and using the services of this invention, this means that the 
50 solutions 2 and 3 are outside the scope of this invention. 

[0126] Should the E2ENP Broker 105 be used and/or the negotiated vocabulary be stored in the Directory Server 
102 or SIP registrar, the new participants can more advantageously get directly the pre-negotiated information from 
such entities, and thus trigger only the Fast-Negotiation (with Economy Principle) 1 08, Re-Negotiation (with Economy 
Principle) 109. 

35 [0127] The temporary asymmetric Initiator 1 01/Responder 1 03 scheme is equivalent to a master/slave configuration, 
where the Initiator 101 acts as a master, and each Responder 103 as a slave. 

[0128] During one of the Pre-Negotiation 1 06, Multi-Stream QoS Synchronization and QoS Correlation 107, Fast-Ne- 
gotiation (with Economy Principle) 1 08, and Re-Negotiation (with Economy Principle) 1 09 phases it is therefore possible 
to resolve possible conflicts arising from Peers 216 independently initiating a phase. 

40 [0129] During the normal conversation phase (i.e. after the Fast-Negotiation 108 phase), multiple Peers 216 can 
detect any QoS Change/QoS Violation simultaneously and this can lead to collisions in requesting to start correspond- 
ingly the Re-Negotiation 1 09 phase. To this extent, the last Peer 21 6 that took the role of Initiator 1 01 shall take again 
such a role and arbitrate the requests among peers. This means that each Peer 21 6 shall retain the identity of the Peer 
216 that last acted as Initiator 1 01 . 

45 [0130] As a worst case, should however such a Peer 216 have left in the meanwhile the communication session, 
the collision would be inevitable. In such a case, each Peer 216 trying to "seize" the IRT, upon reception of similar 
request from other Peers 216 shall block for a random time, and retry when such a time has elapsed, if during this 
time, another Peer 216 has sent a request to seize the IRT, the Peer 216 suspended on said timer would be notified 
accordingly, and consequently it shall abort both the timer and its request to seize the IRT, and consequently take the 

50 role of Responder 1 03. 

[0131] In Fig. 5 an example for the implementation of the E2ENP Broker concept is shown, in which the Session 
Initiation Protocol (SIP) is applied as already mentioned in other parts of this application. SIP Proxy Servers and/or 
SIP Redirect Servers 501 are associated with SIP Registrars 503. This invention proposes to augment the location 
information 505 stored in the databases 504 used by the SIP Registrars 503 by including the QoS Specification and 
55 capabilities information 506 described in this invention. As well as the negotiated QoS information 507 (both the tem- 
porary results being drawn during negotiation/re-negotiation phases, and the ones finally agreed upon). Whenever 
registering with the SIP Registrar 503, users can thus upload the information 506 and 507. The E2ENP Broker 502 is 
a unit which communicates with the SIP Proxy Servers and/or SIP Redirect Servers 501 over a specific interface 508 
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by means of well known mechanisms (e.g. a JAIN SIP Servlet API): Whenever a E2ENP protocol implemented as a 
SIP extension is used, the E2ENP Broker 502 performs the negotiation and re-negotiation phases described in this 
invention in its memory space on behalf of all the peers by using the aforementioned information stored in the Registrar's 
database. The E2ENP Broker 502 communicates with the SIP Registrar 503 over the interface 509. 





The main advantageous differences between the invention and the state of the art 




Technologies 


Comment 


10 
15 
20 


[BorOO] 


The hereby-proposed mechanism for managing 
conference state during sessions and finding 
appropriate configurations, by negotiating for 
configurations and changing them, are based on this 
state of the art. This invention integrates this concept 
with local, peer and network resource reservation 
according to the economy principle. The invention 
introduces additional Adaptation Paths and QoS 
uumiabLb emu leieienceb inese using nanuies. miso, mis 
invention includes terminal capabilities and network 
resource reservation support into the negotiation 
mechanisms. 


25 


[BurnOO], [KasslOO] and [KasslOOa] 


The hereby-proposed mechanism to integrate local and 
remote as well as network resource management in a 
framework is based on this state of the art. In addition, 
this invention defines the protocol that is necessary for 
neootiation of panahilitiPQ nrpfprpncPQ nnH fin*? ctatoo 

and also identifies different versions of the protocol using 
a directory server approach or SIP registrar. 


30 
35 


[Nahr95] 


The hereby-proposed economy principle is based on this 
state of the art. This invention integrates this concept 
with existing Internet protocols, includes Adaptation 
Paths and Indexes and considers other resources like 
battery power or wireless sub-network availability. This 
invention extends the work by first pre-negotiating 
several candidate QoS Contracts and configurations 
thus building a common vocabulary. 


40 
45 


[RFC2533] together with [CONNEG00], 
[CONNEGOOa] or [SDPCN01] 


The hereby-proposed mechanism to represent media 
handling capabilities, express media feature sets and 
match feature sets (compare the bid with the local 
capabilities) is based on this 
state of the art. This invention integrates this concept 
with existing Internet protocols, includes Adaptation 
Paths and integrates local as well as network and peer 
resource reservation. This invention extends the work by 
first pre-negotiating several candidate QoS Contracts 
and configurations thus building a common vocabulary. 



50 
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(continued) 



The main advantageous differences between the invention and the state of the art 


Technologies 


Comment 


[RFC2703] 


The hereby-proposed mechanism for protocol 
independent negotiation of QoS contracts and 
capabilities is based on this state of the art. This 
invention however negotiates QoS contracts, adaptation 
paths and capabilities instead of content as in 
[RFC2703]. This invention also integrates this concept 
with existing Internet protocols, includes Adaptation 
Paths and integrates local as well as network resource 
reservation. This invention extends the work by first pre- 
negotiating several candidate QoS Contracts and 
configurations thus building a common vocabulary 


[SDPNGOO] together with [SDPCNOO], [Ott99], 
[BeserOO] 


The mechanism proposed in this invention to perform 
endpoint capability negotiation and include user 
preferences and network resource reservation is based 
on this state of the art. [SDPCNOO] adds SDP extensions 
for capability negotiation, only. [Ott99] only provides a 
notation for configuration description. [BeserOO] only 
provides SDP extensions necessary for endpoints to 
negotiate codecs. This invention adds the negotiation 
protocol to determine a common set of configuration and 
integrates local, peer and network resource reservation 
by observing the Economy Principle. In addition, the 
invention integrates the process of referencing 
configurations by handles and builds upon QoS 
contracts. Also, this invention not only negotiates 
codecs, but also terminal capabilities and network 
resource reservation 





mechanisms. 


[SIPRES01], together with [CamaOO], [CamaOOa] 


The hereby-proposed invention is based on the integration of 
SIP/SDPwith network resource reservation as a precondition. 
This invention extends the work by first pre-negotiating several 
candidate QoS Contracts and configurations thus building a 
common vocabulary. Also, only references to the 
configuration/QoS contract are referred to later on. In addition, 
this invention integrates local and peer resource management 
with the concept provided by this state of the art by observing 
the Economy Principle. This state of the art only covers one- 
to-one communication with resource reservation and does not 
cover joining operations performed during ongoing sessions 
with negotiations. 


[LevinOI] 


The hereby-proposed invention fulfills many of the 
requirements stated in this state of the art. In addition, this 
invention provides the protocols and the mechanisms to 
integrate local, remote and network resource management into 
a coherent framework observing the Economy Principle. 
[LevinOI] only provides requirements and no protocol or 
mechanisms to enforce the requirements. 
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Claims 

1 . Method for providing guaranteed end-to-end quality of multimedia applications and services, based on integration 
and coordination of local, peer, and network resource management, wherein peers (216) pre-negotiate (106) a 
common set of capabilities, qualities and adaptation mechanism before the actual communication takes place. 

2. Method according to claim 1 , 

comprising the step of pre-negotiating (106) a set of quality-of-service contracts and capabilities between peers. 

3. Method according to anyone of the preceding claims, 

comprising the step of negotiating (1 07) quality-of-service correlation and synchronization aspects among multiple 
streams among multiple peers. 

4. Method according to anyone of the preceding claims, 
characterized in that 

in case of a re- negotiation (109) during streaming the peers (216) refer to a pre-negotiated state, wherein said 
state refers to a given (pre-negotiated) quality-of-service contract and a given (pre-negotiated) set of capabilities. 

5. Method according to anyone of the preceding steps, 
characterized in that 

peers (216) negotiate during the pre-negotiation step (106), at the finest level of resolution, sets of quality-of- 
service contracts on a per-stream basis and/or on a per-stream-association basis, where stream associations are 
bundles of streams from one sender peer to a receiver peer. 

6. Method according to anyone of the preceding step, 
characterized in that 

peers (216) are informed about changes in capability configuration. 

7. Method according to anyone of the preceding claims, 

wherein pre-negotiated alternative quality and configuration information of a given type of stream may already be 
available at a server for clients to choose from. 

8. Method according to anyone of the preceding claims, 

comprising the steps of Protocol Discovery (104), Pre-Negotiation (106), optional Multi-Stream QoS Synchroniza- 
tion and QoS Correlation (107), Fast-Negotiation (with Economy Principle) (108), Re-Negotiation (with Economy 
Principle) (109) and Resource Reservation Release (110). 

9. Method according to claim 8, 

wherein ail the six phases are concatenated and can be executed either continuously or at different times (but still 
strictly following the order indicated in claim 8). 

10. Method according to claim 9, 

wherein the Multi-Stream QoS Synchronization and QoS Correlation (107) phase is optional and required only if 
an Initiator (101) communicate with multiple peers (216) by using multiple streams, which need to be correlated 
and synchronized, based on user policies to be enforced at the Initiator (101) side only. 

11. Method according to claim 10, 

wherein the Protocol Discovery (1 04) and Pre-Negotiation (1 06) phases are executed a priori, and the results can 
then be applied to multiple successive communication sessions, whereby each communication session is initiated 
with a specific optional Multi-Stream QoS Synchronization and QoS Correlation phase (107). 

12. Method according to claim 11, 

wherein, if the results of the Multi-Stream QoS Synchronization and QoS-Correlation phase are applicable to mul- 
tiple successive communication sessions, each of said communication sessions can be initiated with a specific 
Fast Negotiation phase (108). 

13. Method according to anyone of claims 8 to 12, 

wherein the protocol interacts with Local resource management units (206) during Pre-Negotiation (106), Multi- 
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Stream QoS Synchronization and QoS Correlation (107), Fast Negotiation (108), Re-Negotiation (109) and Re- 
source Release (110) phases. 

14. Method according to anyone of claims 8 to 13, 
characterized by 

a resource admission control and resource reservation applied according to the following order: at the initiator 
(101) first, then at the responder(s) (1 03), and finally for the network using (207). 

15. Method according to claim 14, 

wherein in the first two said steps local resource management tasks like real-time CPU scheduling, memory man- 
agement, and power management are addressed. 

16. Method according to anyone of claims 8 to 15, 

wherein for the resource release (110), first network resources, then peer (216) and finally local resources are 
released. 

17. Method according to anyone of claims 8 to 16, 

wherein during runtime of a so established multimedia session, at any time any component of any peer (21 6) may 
request an adaptation, thus eventually triggering a Re-Negotiation phase (109). 

18. Method according to anyone of claims 8 to 17, 

comprising the step of p re-negotiation of the type of E2ENP during Protocol Discovery phase (104), either by 
forcing peers (101 , 103) to query a Directory Server (102) which may be implemented as a SIP registrar, or by 
having the peers announcing such information. 

19. Method according to claim 18, 

comprising the step of Pre-Negotiation of capabilities during Pre-Negotiation phase (106). 

20. Method according to anyone of claims 8 to 19, 
comprising the step of 

pre-negotiation of a complete codec list during the pre-negotiation phase (1 06). 

21. Method according to anyone of claims 8 to 20, 
comprising the step of 

pre-negotiation of adaptation paths at stream level during the Pre-Negotiation phase (106). 

22. Method according to anyone of claims 8 to 21 , 
comprising the step of 

pre-negotiation of Adaptation Paths at stream aggregation level during Multi-Stream QoS Synchronization and 
QoS Correlation phase (107). 

23. Method according to anyone of claims 8 to 22, 
characterized by the step of 

indexing pre-negotiated QoS Contracts and Capabilities for speeding up the Fast Negotiation phase (108). 

24. Method according to anyone of claims 8 to 23, 
characterized by the step of 

indexing pre-negotiated QoS Contracts and Capabilities for speeding up the Re-Negotiation phase (109). 

25. Method according to anyone of claims 8 to 24, 
characterized by the step of 

handling installation/deinstallation of Capabilities even at runtime, by exchanging asynchronous messages among 
peers for notifying such events. 

26. End-to-End negotiation protocol for telecommunications, 
characterized in that 

a QoS-enabled communication session is established by pre-negotiating alternative QoS aspects and capabilities 
on an end-to-end basis to establish beforehand a common level of alternative QoS and capabilities, the use of 
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which all peers of the telecommunication session can agree upon. 

27. Broker for End-to-End-Negotiation of quality-of-service, 

relieving peers of a network from carrying out the Pre-Negotiation phase (106) and, optionally, the Multi-Stream 
QoS Synchronization and QoS Correlation phase (107). 

28. Computer program implementing a method according to anyone of the preceding claims when run on a computer. 

29. Peer, configured for implementing a method according to anyone of the preceding claims, 

comprising a coordination unit (204) coordinating the different phases of the negotiation process of the distributed 
resource management process. 

30. Peer according to claim 29, 
characterized in that 

the coordination unit (204) commands a Protocol Discovery (1 04), and then triggers and coordinates Pre-Negoti- 
ation (106), optional Multi-Stream QoS Synchronization and QoS Correlation (107), Fast-Negotiation (108) with 
Economy Principle, Re-Negotiation (1 09) with Economy Principle, and Resource Reservation Release (110) phase. 

31 . Peer according to claim 29 or 30, 
characterized by 

a protocol discovery unit (21 3) for advertising and querying information about the end-to-end negotiation protocol 
to be used. 

32. Peer according to anyone of claims 29 to 31 , 
characterized by 

a session protocol unit (205) allowing the coordination unit (204) to carry out the different phases of the coordination 
process with other peers (216). 

33. Peer according to anyone of claims 29 to 32, 
characterized by 

interfaces (211) connecting the coordination unit (204) to local resource management units (206). 

34. Peer according to anyone of the claims 29 to 32, 
characterized by 

interfaces (214) connecting the coordination unit (204) to the protocol discovery unit (213). 

35. Peer according to anyone of the claims 29 to 32, 
characterized by 

interfaces (210) connecting the coordination unit (204) to the session protocol unit (205). 

36. Peer according to anyone of the claims 29 to 32, 
characterized by 

interfaces (209) connecting the coordination unit (204) to a FSM Engine Unit (203). 

37. Peer according to anyone of the claims 29 to 32, 
characterized by 

interfaces (209) connecting the coordination unit (204) to a network resource reservation unit (207). 

38. Protocol according to anyone of the claims 25 and 26, 
characterized in that 

the negotiation and re-negotiation of capabilities include signaling of the selected codecs and the configurations 
thereof. 
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